As computing devices become increasingly complex, viruses and malware also are becoming increasingly complex and difficult to detect and prevent. While the prior art includes many approaches for scanning non-volatile storage such as a hard disk drive for such threats, the prior art includes few satisfactory solutions for detecting malicious code loaded into memory or the processor itself. The prior art also is lacking in the ability to detect malicious instructions before they are executed, particularly in situations where the malicious instructions are “new” or are known instructions used in a new way and are not part of a well-known virus or malware.
FIG. 1 depicts an exemplary prior art computing device 100 comprising processor 110 and memory 120. One of ordinary skill in the art will understand that processor 110 can include a single processor core or multiples processor cores as well as numerous cache memories, as is known in the prior art.
In FIG. 2, software code and user data are loaded into memory 120. In this example, each set of software code is assigned a certain range in memory 120. Operating system 210 is assigned addresses 0001-0200, utility program 220 is assigned addresses 0201-0300, application program 230 is assigned addresses 0301-0350, application program 240 is assigned addresses 0351-0450, user data 250 is assigned addresses 0450-0700, and the addresses 0701-9999 at this point are unassigned addresses 260. These addresses are intentionally simplified for purposes of discussion and illustration, and one of ordinary skill in the art will appreciate that in an actual implementation, addresses would be binary numbers instead of base-10 numbers and potentially would span a much larger address space. For instance, typical address space in prior art memory 120 includes 32-bit and 64-bit addresses.
FIG. 3 shows a simplified sequence of instructions stored in memory. Address 0001 contains an ADD instruction, address 0002 contains a BRANCH instruction, address 0003 contains a LOAD instruction, address 0004 contains a STORE instruction, and address 0005 contains an ADD instruction. The BRANCH instruction at address 0002, when executed, will cause the processor to next execute the instruction at address 0004.
FIG. 4 depicts a common approach of malicious code in the prior art. Here, the instruction at address 0005 is a BRANCH instruction to the address stored in Register A, which is address 10000. However, in this example, a virus or malware hijacks the BRANCH instruction by modifying the contents of Register A to cause processor 110 to execute the instruction stored at address 9000, which is the beginning point for malicious code. This causes the malicious instructions to be executed instead of the intended instructions. This is often referred to as a “control-flow hijack,” because the malicious instructions interrupt and take over the control-flow of processor 110. A control-flow hijack represents the very first point in which an attacker is able to redirect control-flow of a running process.
What is needed is a mechanism for detecting suspicious BRANCH instructions and to prevent the system from performing the BRANCH if the associated address is likely to contain malicious instructions.
Another aspect of the prior art is shown in FIG. 11. Processor 110 runs operating system 210. Operating system 210 comprises scheduler 1110 and asynchronous procedure calls unit 1120. Operating system 210 is capable of operating multiple threads at once (such as threads 1130, 1140, 1150, and 1160), where each thread is a set of code that form a process or related processes. Scheduler 1110 determines which threads to run and it follows various algorithms to determine when to start and stop a particular thread. One drawback of certain prior art operating systems 210 (such as Microsoft Windows®) is that operating system 210 does not indicate to other software when it is starting or stopping a thread (known as thread context switching). As a result, malware prevention software is unable to distinguish between threads that may potentially contain a threat and threads that are relatively innocuous, which means that malware prevention software must analyze all threads, which may add unnecessary performance overhead to the operating system.
What is further needed is a mechanism to allow code outside of operating system 210 to identify when each thread starts and stops so that it can better target suspicious instructions.